Cluster API

#cloud #architecture #cloud-native #cncf/cluster-api #kubernetes/cluster #provisioning

개요

|600
아키텍처 부분을 보면 알겠지만, 사실 이 그림은 거북이들을 거꾸로 배치시켜야 하지 않을까
클러스터 API(aka CAPI)는 클러스터에서 클러스터를 관리하는 툴이다.
선언적으로 리소스를 관리할 수 있도록 해주는 쿠버네티스의 장점을 클러스터 관리 영역에 접목시킨 기술이다.
클러스터와 관련한 커스텀 리소스를 이용하여 기본 클러스터에서 여러 작업 클러스터를 손 쉽게 구축 관리할 수 있다.

구체적으로 가지는 특징은 다음과 같다.

clusterctl이라는 cli 툴을 사용하거나 오퍼레이터를 이용할 수 있다.
cli는 단순하게 배울 때 좋고, 구체적인 운영 작업에 들어갈 땐 오퍼레이터를 활용하는 것이 권장된다.

공식 문서를 보고 좀 놀랐는데, 정말 기본적인 사용법에 대한 내용은 거의 없다!
어떤 식으로 CRD를 써야 하고 어떤 것들이 있는지 자세히 안 나옴..
근데 디벨로핑 가이드 보면 레포 구조에 각 리소스 동작 원리 등의 내용이 엄청 세세하다.
아무래도 다양한 프로바이더를 위한 것으로 보이는데 아무튼 원한다면 깊게 원리를 파고들 수 있다.

아키텍처

클러스터가 클러스터를 관리하는 구조를 개략적으로 나타내면 다음과 같다.

가장 기본이 되는 클러스터는 관리 클러스터(MGMT Cluster) 라고 부른다.
이 클러스터에는 관리 대상이 되어줄 각종 클러스터에 대한 커스텀 리소스와, 실제 프로비저닝과 관리를 도와줄 컨트롤러나 프로바이더가 들어있다.
Cluster API를 운용한다는 것은 이 클러스터를 조작하는 행위를 말한다.

관리 클러스터에서 관리자가 선언적으로 리소스를 생성했다면, 해당 리소스를 토대로 실제로 클러스터를 생성하는 임무는 프로바이더가 수행한다.
(프로바이더에 대해서는 아래에서 조금 더 자세히 다룬다.)
이렇게 만들어지는 대상 클러스터를 워크로드 클러스터(Workload Cluster)라고 부른다.

여기에 번외 격으로, 관리 클러스터를 부트스트랩하기 위한 하나의 클러스터를 더 상정하기도 한다.
관리 클러스터도 명확하게 Cluster API에 기반하여 관리하기 위한 운영 전략으로, 클러스터를 클러스터로 관리한다는 Cluster API의 핵심 가치에 부합하는 방식이다.
이러한 부트스트랩 클러스터는 구축 초기에만 활용되며 관리 클러스터 구축이 완료되기 전 일시적으로 로컬 환경에서 간단하게 만들어 활용한다.
그렇기 때문에 KIND 같은 것을 간단하게 이용하는 편이다.
문서에서 권장하는 패턴은 다음과 같다.

프로바이더

문서에서는 관리 클러스터에서 활용하는 간단한 커스텀 리소스 구조와 프로바이더에 대해 설명하고 있다.

Cluster API는 말 그대로 그저 API에 가깝고, 실제로 클러스터를 구축하고 조작하는 것은 각 벤더 별로 제공하는 프로바이더가 수행한다.
가령 AWS 환경에서 타겟 클러스터를 구축하고 싶다면 CAPA(Cluster Api Provider AWS)를 이용하는 식이다.
Cluster API는 클러스터를 구축하는데 필요한 개념들을 추상화시켜 벤더 종속적이지 않은 커스텀 리소스를 정의하고, 각 프로바이더가 이 리소스들을 지원할 세부 구현체 리소스를 만들도록 설계됐다.
(커스텀 리소스에 대해서는 아래에서 더 자세히 다룬다.)

다양한 프로바이더가 있을 수 있는데, 먼저 크게 3가지 종류의 프로바이더를 분류할 수 있다. 전체 리스트

K0s처럼 모든 종류의 프로바이더를 전부 지원하는 케이스도 있으나, 대체로 인프라 프로바이더가 가장 많다.
부트스트랩, 컨트롤 플레인 프로바이더는 어차피 인프라 환경에 크게 종속되지 않는 경우가 많고 실제 자원을 제공하는 게 아니라 동작, 설치 작업을 수행하기 때문이다.

인프라 프로바이더는 Cluster API로 어떤 리소스가 생성됐을 때 실제로 물리 자원을 프로비저닝해 제공한다.
자원을 프로비저닝한다는 점에서 클라우드 벤더를 떠올리기 쉽다.
그러나 베어메탈 환경에서도 사용할 수 있는 몇 가지 프로바이더가 존재한다.
몇가지 예를 들자면,

오픈스택 프로바이더도 있는데, 이 케이스는 순수 베어메탈이라 하기엔 애매하다 생각해 언급하지 않는다.

커스텀 리소스

그렇다면 클러스터 API에서 지원하는 커스텀 리소스는 무엇이며, 어떻게 각 프로바이더 별로 세부 설정을 할 수 있도록 하는가?
먼저 전체적인 리소스 구조도는 다음과 같이 표현할 수 있다.

여기에서 Cluster, Machine(초록색)은 Cluster API에서 제공하는 벤더 독립적인 순수한 추상체이다.
보다시피 Cluster API의 리소스는 Ref 필드를 통해 프로바이더들이 제공할 수 있는 세부 구현체 리소스를 참조한다.
(해당 사양을 구현하는 어떤 프로바이더가 와도 상관없기에 X라고 표현했다.)

각 리소스를 조금 더 세부적으로 살펴본다.

클러스터 리소스는 컨트롤 플레인 리소스를 명시하여 컨트롤 플레인을 설정한다.
그러나 데이터 플레인에 대해서는 오히려 의존 관계가 역전되어 머신 리소스가 클러스터 리소스를 참조하는 구조이다.
이러한 구조를 통해 하나의 클러스터에 하나의 컨트롤 플레인, 그러면서 여러 개의 데이터 플레인을 배치하는 설계가 가능하다.

위의 그림은 단일 마스터 노드, 단일 워커 노드를 두는 상태의 그림이다.
Cluster API는 당연히 여러 머신을 하나의 단위로 묶는 방법 역시 제공하고 있다.

이를 지원하는 Cluster API의 리소스가 바로 MachineDeployment이다.
이름과 같이 이 리소스는 쿠버네티스의 디플로이먼트와 똑같이 머신을 관리한다.
실제로 동작할 때도 디플로이먼트 - 레플리카셋 - 파드의 관계처럼 MachineDeployment - MachineSet - Machine의 구조를 가진다.
실제 참조하는 리소스는 템플릿 리소스인데, 양식은 사실 일반 구현체 리소스와 다를 게 없다.
대신 레플리카마다 실제 구현체 리소스가 생기도록 해주는 템플릿으로서 기능한다.

보다시피 마스터 노드를 여러 개 두고 싶을 때는 컨트롤 플레인 리소스에서 설정하면 된다.

예시로 Kubeadm 부트스트랩, 컨트롤플레인 프로바이더와 MicroVM 인프라 프로바이더를 이용한 구조도를 그려본다. 참고

ClusterResourceSet 리소스는 Cluster API에서 제공하는 리소스로, 클러스터를 구축하면서 바로 넣고 싶은 리소스들을 정의한다.
이를 통해 CNI, CSI 등 클러스터 운용에 필요한 리소스들을 바로 배치하여 클러스터를 사용 가능한 상태로 만들 수 있다는 장점이 있다.

Cluster API의 전체 커스텀 리소스

Cluster API에서는 MachineHeathCheck와 같은 다른 여러 가지 순수 커스텀 리소스도 제공하고 있다.
공식 문서 자체로는 전체 커스텀 리소스에 대한 개괄적인 장표를 따로 제공하지 않는다.
대신 전체 리소스는 crd dev로 확인해볼 수 있으니 참고

이렇게 템플릿 리소스로 세팅하면 상위 리소스에서 replica를 세팅해 여러 개의 복제 마스터 노드, 워커 노드를 둘 수 있다.

운영 방법

이 문단부터는 Cluster API를 이용해 버전 업그레이드, 장애 처리를 하는 등의 다양한 운영 전략을 다룬다.

사용 흐름

로고와 같이 cluster api는 3개의 클러스터 개념을 사용하며 이 순서로 클러스터를 배치한다.

https://karmada.io/

관련 문서

EXPLAIN - 파생 문서

이름0related생성 일자

Dataview: No results to show for table query.

기타 문서

Z0-연관 knowledge, Z1-트러블슈팅 Z2-디자인,설계, Z3-임시, Z5-프로젝트,아카이브, Z8,9-미분류,미완
이름1코드타입생성 일자
클러스터 api 인프라 프로바이더 탐색Z8topic2025-06-23 14:53

참고